Methods and systems for enhancing privacy on distributed ledger-based networks

ABSTRACT

One or more embodiments described herein disclose methods and systems that are directed at providing enhanced privacy and security to distributed ledger-based networks (DLNs) via the implementation of zero-knowledge proofs (ZKPs) in the DLNs. ZKPs allow participants of DLNs to make statements on the DLNs about some private information and to prove the truth of the information without having to necessarily reveal the private information publicly. As such, the disclosed methods and systems directed at the ZKP-enabled DLNs provide privacy to participants of the DLNs while still allowing the DLNs to remain as consensus-based networks.

CROSS-REFERENCE TO RELATED PATENT APPLICATION

This application claims priority to and the benefit of U.S. ProvisionalApplication No. 62/719,636, filed Aug. 18, 2018, entitled “Methods andSystems of ZKP-Based Secure PE Transactions on Public Networks,” andU.S. Provisional Application No. 62/748,002, filed Oct. 19, 2018,entitled “Methods and Systems of ZKP-Based Secure Private EnterpriseTransactions on Public Networks,” both of which are incorporated hereinby reference in their entirety.

FIELD OF THE DISCLOSURE

Distributed ledger-based networks (DLNs) dispense with the need for acentral authority to manage the operations of the networks due to theirtransparency and consensus-based verification mechanisms for validatingactions occurring on the DLNs, which allow participants of the networksto trust the accuracy of the validations without the central authority.The transparency and consensus-based verification mechanisms, however,compromise the privacy of the actions and the involved parties, asrelevant information has to be shared with at least a substantialportion of the participants of the DLNs for the actions to be validated.The disclosure illustrates how the privacy and security of such actionscan be enhanced with the use of zero-knowledge proofs (ZKPs) that can beused to verify the validity of at least some aspects of the actionswithout private information related to the actions necessarily beingrevealed publicly. The disclosure discloses methods and systems that aredirected at providing enhanced security and privacy to actions conductedon ZKP-enabled DLNs.

BACKGROUND

Organizations can use private networks as well as public networks suchas the internet and distributed ledger-based networks (DLNs) to manageand track the production and shipping of large quantities of items orassets. The use of private networks, however, can be inefficient andcostly, while public networks may not provide the desired level ofprivacy and/or security. For example, public DLNs can expose, by virtueof being public networks, details of private interactions occurring onthe networks.

BRIEF DESCRIPTION OF THE FIGURES

FIG. 1 shows a distributed ledger-based network configured for use inmanaging and conducting a private transaction between two parties thatare participants of the network, according to some embodiment.

FIG. 2 shows a flow chart illustrating the minting a token on adistributed ledger-based network to represent a real world or physicalasset on the distributed ledger-based network, according to someembodiment.

FIG. 3 shows a flow chart illustrating the creation or generation of newtoken commitment on the distributed ledger-based network to representthe transfer of a real-world or physical asset from a sender to arecipient, according to some embodiment,

SUMMARY

Some embodiments of the current disclosure disclose methods and systemsthat are directed at providing enhanced security and privacy to actionsconducted on ZKP-enabled DLNs. For example, the actions may includerepresenting the transfer of an asset from a sender to a recipient,where the asset is represented on the ZKP-enabled DLN by a first tokencommitment. In such embodiments, the methods may include the steps of:receiving a request that is configured to cause a transfer of the assetfrom the sender to the recipient; providing by a provider, in responseto the request and to a self-executing code segment on the distributedledger, a zero-knowledge proof (ZKP) that the provider of the ZKP hasknowledge of an identity of an asset token, where (1) an application ofa first hashing function on the asset token generating the first tokencommitment, and/or (2) an application of a second hashing function onthe asset token generating a second token commitment representing theasset on the distributed ledger. Further, the methods may include thestep of receiving, upon verification of the ZKP by the self-executingcode segment, a confirmation confirming an addition of the second tokencommitment onto a token commitments data structure on the distributedledger.

DETAILED DESCRIPTION

In some embodiments, parties participating in a transaction may elect touse a public distributed ledger-based network (DLN) to document thedetails of the transaction and manage its operations. DLNs can providedecentralized platforms that are transparent to at least all theparticipants of the networks, if not to the public at large, and assuch, can be viewed as consensus-based platforms that facilitate trustbetween transaction participants without the need for a centralauthority to administer the network. For example, parties participatingin a transaction for a sale of a digital music file can use aself-executing code or program (e.g., a smart contract) on the DLN(e.g., a blockchain) to manage the sale of the music file. Theself-executing code or smart contract can regulate the exchange of themusic file and the correct payment for the file between the partieswithout involvement from a third party. In some embodiments, the DLNscan also be used to manage transactions involving physical (e.g.,non-digital) assets. In some implementations, this can be accomplishedby using tokens to represent the assets, and a sale of an asset can berepresented by the transfer of the token representing the asset from oneparty (e.g., the seller) to a second party (e.g., the buyer).

In some embodiments, a DLN can be and/or support a blockchain.Throughout the instant disclosure, in some embodiments, the terms“distributed ledger-based network” and “blockchain network” may be usedinterchangeably. Similarly, in some embodiments, the terms“self-executing code” or “self-executing code segment” and “smartcontract” may be used interchangeably. Further, in some embodiments, theterm “transaction” may be used to refer to off-chain transactions (e.g.,transactions involving the sale of physical or digital assets betweenparties) and/or on-chain representation of these off-chain transactions(e.g., the transaction of tokens that represent the assets on theblockchain network). Whether the term refers to the former or the lattercase should be clear from context. The terms “off-chain” or “off-theDLN” are to be understood to mean “not on the blockchain network” or“not on the DLN.” For example, a statement such as “the application of ahashing function is performed off-the DLN” is to be understood asmeaning “the application of the hashing function is not performed on theDLN (and is performed elsewhere)”.

As noted above, in some embodiments, the trust the distributedledger-based networks provide with no need for a central authorityderives from the transparency of the networks to at least all theparticipants of the network (and in the case of public networks, to thepublic at large). This transparency, however, can reduce or eveneliminate any privacy or confidentiality that participants need or seekwhen interacting with the network or its participants. For example, inthe case of public networks, any interested person can access andinspect the distributed ledgers on the networks to obtain detailedinformation on all transactions that are represented on the ledgerssince the inception of the networks (as the ledgers are, in at leastmost cases, largely immutable). In some implementations, the lack ofprivacy or confidentiality can render the use of a public ledger-basednetwork untenable. For instance, a pharmacy using a public blockchainnetwork to manage the fulfillment of orders for shipment of prescriptiondrugs without a mechanism to conceal at least some aspects of thetransaction would publicly expose personal and health-related data ofits customers (thereby violating their privacy and possibly healthprivacy laws).

In some cases, private DLNs can be used to provide participants ameasure of privacy that may not be available on public networks. Theprivacy afforded by private (non-ZKP-enabled) DLNs, however, is far fromadequate for most purposes (how ZKPs can be used to provide privacy toprivate and/or public blockchain networks will be discussed in detailsbelow). For example, with reference to the above example, the personaland health-related data of customers would still be available forinspection by other members of the private non-ZKP-enabled DLN (even ifthe data is hidden from the public). Further, private non-ZKP-enabledDLNs would be burdensome to maintain as, amongst other reasons,applications developed for public blockchain networks would notseamlessly interoperate on private non-ZKP-enabled blockchain networks.

The inefficiency and cost associated with private non-ZKP-enabled DLNsmay be illustrated with reference to the internet, which suffers fromseveral privacy and security-related ills due to the openness of thenetwork to anyone capable of accessing the network. Setting up a“private” intranet network can be one way to combat the noted privacyand security-related ills. Such private networks, however, are likely toseverely lag in their developments, and even then to be costly tomaintain, compared to the open internet, as the closed nature of theprivate networks would limit interoperability of applications developedfor the open or public internet. Analogously, a private DLN would lag inits development compared to a public DLN and still be costly tomaintain. One or more embodiments described herein disclose methods andsystems that are directed at providing enhanced privacy and security toDLNs via the implementation of ZKPs in the DLNs. It is to be noted that,although descriptions of these embodiments refer to public DLNs, themethods and systems equally apply to private DLNs.

In some embodiments, as noted above, the current disclosure disclosesmethods and systems that provide privacy to participants of atransaction on a ZKP-enabled DLN while retaining the level of trustafforded by decentralized networks (i.e., with no central authority)such as DLNs. For example, one or more of the methods and systemsdisclosed herein allow for the identities of parties to a transaction(e.g., a sale or transfer of an asset between the parties) as well asdetails of the transaction (e.g., details of the assets beingtransferred) to remain secret when a public blockchain network is usedto manage the transaction. Referring to the example provided above, oneor more of the disclosed methods and systems allow the pharmacy to use apublic blockchain network to facilitate the shipment of the drugswithout revealing on the blockchain network (or publicly) anyidentifying information related to the assets (i.e., the drugs), thesender (i.e., the pharmacy) and/or the recipient of the assets (i.e.,the clients), while depending on the trust afforded by the blockchainnetwork at least partly as a result of the transparency inherent topublic blockchain networks. In such examples, the sender and therecipient may be represented by their respective public keys on theblockchain network.

FIG. 1 shows a ZKP-enabled DLN configured for use in managing andrepresenting a private transaction between two parties that areparticipants of the network, in particular a public network, accordingto some embodiment. In some embodiments, the ZKP-enabled DLN orblockchain network 100 includes a plurality of computing nodes 102 a-102e configured to communicate amongst each other via a peer-to-peer (P2P)connection. In some implementations, the computing nodes 102 a-102 e canbe computing devices including but not limited to computers, servers,processors, data/information processing machines or systems, and/or thelike, and may include data storage systems such as databases, memories(volatile and/or non-volatile), etc. In some implementations, the P2Pconnections may be provided by wired and/or wireless communicationssystems or networks (not shown) such as but not limited to the internet,intranet, local area networks (LANs), wide area networks (WANs), etc.,utilizing wireless communication protocols or standards such as WiFi®,LTE®, WiMAX®, and/or the like.

In some embodiments, the ZKP-enabled DLN 100 may include self-executingcodes or smart contracts that are configured to execute upon fulfillmentof conditions that are agreed upon between transacting parties. Forexample, some or all of the computing nodes 102 a-102 e may includecopies of a self-executing code that self-execute upon fulfillment ofthe conditions. In some implementations, the computing nodes 102 a-102 emay communicate amongst each other with the results of the executions oftheir respective self-executing codes, for example, to arrive at aconsensus on the results. In some implementations, one or a few of thecomputing nodes 102 a-102 e may have self-executing codes thatself-execute, and the results would be transmitted to the rest of thecomputing nodes 102 a-102 e for confirmation.

In some embodiments, a self-executing code or a smart contract canfacilitate the completion of transactions on the ZKP-enabled DLN 100 byproviding the transacting parties confidence that the other party woulddeliver the promised product or payment. For example, with reference tothe above example related to the sale of a digital music file, a smartcontract can be used to verify that the seller of the file is in fact anowner of the file, the buyer of the music file has adequate resource topay for the music, etc. Further, the smart contract can facilitate theexchange of the music file by allowing the transfer of a payment tooccur only after the transfer of the music file is completed (andvalidated).

In some embodiments, the ZKP-enabled DLN 100 may be linked to one ormore oracles (not shown) or data feeds that provide external data to theZKP-enabled DLN 100. In some implementations, as discussed above,self-executing codes or smart contracts can automatically execute uponrealization of some conditions of a transaction, and the oracles mayprovide the data that can be used to evaluate whether the conditions aremet. For example, a transaction may be contingent on the price of astock, a weather condition, etc., and an oracle may provide therequisite information to the smart contract facilitating thetransaction. The smart contract, upon receiving the information, mayself-execute after determining that the condition for the transactionhas been fulfilled. In some embodiments, the oracles may facilitate forthe smart contracts to send data out to external systems. For example, asmart contract may be configured to send out information to a smartphonewhen an account on the ZKP-enabled DLN 100 receives a payment, and anoracle may serve as a transit hub for the data including the informationduring its transmission to the smartphone.

In some embodiments, at least a substantial number of the computingnodes 102 a-102 e include copies of a distributed ledger 104 a-104 eonto which transactions that occur on the network are recorded. Therecording of the transactions on the distributed ledger 104 a-104 e mayoccur when some substantial proportion of the computing nodes 102 a-102e, or a subset thereof, agree on the validity of the transactions. Thedistributed ledger 104 a-104 e can be immutable or nearly immutable inthe sense that to alter the distributed ledger 104 a-104 e, at leastthis substantial portion of the computing nodes 102 a-102 e would haveto agree, which can be increasingly difficult when the number ofcomputing nodes 102 a-102 e is large (and the distributed ledger 104a-104 e gets longer).

As noted above, the ZKP-enabled DLN 100 can be used to facilitatetransactions that involve digital assets (e.g., sale of digital musicfiles). In some embodiments, the ZKP-enabled DLN 100 can also be used tofacilitate transactions of assets that occur off-chain or off-line(e.g., transactions of physical assets). In some implementations,off-chain assets can be represented by tokens (e.g., token commitments)on the ZKP-enabled DLN 100, and the sale or transfer of the off-chainassets can be represented on the ZKP-enabled DLN 100 by the transfer ofthe tokens between the blockchain accounts of the transacting parties.In some implementations, the types of tokens used to represent theoff-chain assets can depend on the nature of the assets themselves. Forexample, fungible products (e.g., some amount of gasoline or a currency)can be represented with fungible tokens while non-fungible products(e.g., distinguishable products such as a product with a serial number)can be represented by non-fungible tokens. FIG. 1 shows an exampleembodiment of a transaction that involves the sale of an off-chain asset(e.g., vehicle 112) from a first transaction participant 110 a to asecond transaction participant 110 b. In such example, the vehicle maybe represented on the ZKP-enabled DLN 100 with a non-fungible token thatcan be transferred from the first transaction participant 110 a to thesecond transaction participant 110 b to represent the sale or transferof the vehicle 112 during the transaction between the two parties. Insome embodiments, tokens may be stored off-chain, i.e., off of theZKP-enabled DLN 100. For example, tokens may be stored in storagesystems or databases that are linked with the ZKP-enabled DLN 100. Forinstance, if the ZKP-enabled DLN 100 is a ZKP-enabled Ethereumblockchain network, the tokens may be stored in the Swarm database. Insome embodiments, the tokens may be stored on the ZKP-enabled DLN 100(e.g., in the storage systems associated with the computing nodes 102a-102 e).

In some embodiments, as noted above, transactions that occur on theZKP-enabled DLN 100 (including off-chain transactions that arerepresented on the ZKP-enabled DLN 100 with the use of tokens, forexample) are recorded onto at least a substantial number of thedistributed ledgers 104 a-104 e that exist on the ZKP-enabled DLN 100.For example, a transaction between a first transaction participant 110 aand a second transaction participant 110 b on the ZKP-enabled DLN 100representing the transfer of an off-chain asset 112 from the former tothe latter would be recorded on all or nearly all of the distributedledgers 104 a-104 e once the transaction details are accepted as validby the participants of the ZKP-enabled DLN 100. In the case of ablockchain network that is not ZKP-enabled, however, the firsttransaction participant 110 a and the second transaction participant 110b are afforded little or no privacy as all or nearly all the details ofthe transaction are made public or visible to all that have access tothe blockchain network (the public, in case of public blockchains), suchdetails including confidential information on the transactingparticipants, the asset being transacted, the tokens used to representthe asset and the representation of its transfer on the blockchainnetwork, and/or the like. In some embodiments, the present disclosurediscloses methods and systems for providing privacy to transactions thatoccur or are represented on public blockchains with the use of zeroknowledge proofs (ZKPs).

In some embodiments, ZKPs can be used by a first entity, the “prover” or“provider” of the proofs, to convince a second entity, the “verifier” ofthe proofs, that a statement about some secret information is truthfulwithout having to reveal the secret information to the verifier. ZKPscan be interactive, i.e., require interaction from the prover for theverifier to verify the truthfulness of the statement. In someembodiments, the ZKPs can be non-interactive, requiring no furtherinteraction from the prover for the verifier to verify the statement.Examples of non-interactive ZKPs include zero-knowledge succinctnon-interactive argument of knowledge (zk-SNARK), zero-knowledgescalable transparent argument of knowledge (zk-STARK), etc. Discussionsof ZKPs can be found in U.S. patent application Ser. No. 16/383,845,filed on Apr. 15, 2019 and entitled “Methods and Systems for IdentifyingAnonymized Participants of Distributed Ledger-Based Networks UsingZero-Knowledge Proofs,” which is incorporated by reference herein in itsentirety.

FIG. 2 shows a flow chart illustrating the steps of minting a token on adistributed ledger to represent a real world or physical asset on thedistributed ledger, according to some embodiment. To represent anoff-chain transaction for a non-fungible asset such as the transfer of avehicle asset 112 from a first transaction participant 110 a (referredhereinafter as the sender 110 a) to a second transaction participant 110b (referred hereinafter as the recipient 110 b) on the ZKP-enabled DLN100, in some embodiments, the sender 110 a may generate, at 204 andusing the computing node 102 a, an asset identifier that can serve as aunique identifier for the asset while concealing the asset's identity.In some implementations, the asset identifier may be generated inresponse to a request, at 202, to have a physical asset represented on aZKP-enabled DLN 100. For example, the sender 110 a can generate, usingthe computing node 102 a, an alpha-numeric value that is uniquelyassociated with some identifying parameters (e.g., serial numbers, modelnumbers, etc.) of the asset, and the alpha-numeric value can be used asthe asset identifier that hides the real identity of the asset. Asanother example, a unique asset identifier can be generated bycryptographically hashing the identifying parameters of the non-fungibleasset to generate an asset token that can serve as the unique assetidentifier. The cryptographic hashing includes the application of acryptographic hashing algorithm such as but not limited to the SHA-256algorithm, on the identifying parameters. For instance, an asset tokencan be generated for the vehicle asset 112 by applying a hashingfunction (e.g., SHA-256) on one or more of the identifying parameters ofthe vehicle such as the vehicle identification number, model type, modelyear, etc. Accordingly, the asset token can serve as a unique assetidentifier without exposing or revealing to other participants of theZKP-enabled DLN 100 any of the identifying parameters of the asset(i.e., vehicle). In some embodiments, the hashing can occur off theZKP-enabled DLN 100. For example, if the ZKP-enabled DLN 100 is aZKP-enabled Ethereum blockchain network, in some implementations, theasset token can be generated and stored off the Ethereum blockchainnetwork at the Swarm storage network/database.

At 206, an off-chain non-fungible asset (e.g., physical asset such asthe vehicle 112) can be registered or represented on the ZKP-enabled DLN100 for the first time by generating or minting a non-fungible tokencommitment that encodes at least some aspects of the non-fungible assetand/or the ownership of the asset on the ZKP-enabled DLN 100. In someembodiments, minting of a token commitment may refer to the registrationor representation of an asset on the ZKP-enabled DLN 100 by a tokencommitment for the first time. As will be discussed below, new tokencommitments may be generated later to represent an asset that is beingrepresented on the ZKP-enabled DLN 100 by an existing token commitment.In such cases, however, the asset is being transferred to a new owner,and the generation of the new token commitment may be accompanied by thenullification of the existing token commitment (which indicates that theasset does not belong to the initial owner anymore). In any case,whether an asset (e.g., non-fungible asset) is being registered orrepresented on the ZKP-enabled DLN 100 for the first time by the mintingof a token commitment or the transfer of the asset from one owner toanother is being registered on the ZKP-enabled DLN 100 by generation ofa new token commitment, the minted token commitment and/or the new tokencommitment may encode at least some aspects of the asset and/or theownership of the asset. To encode the aspects of the non-fungible asset,in some implementations, a cryptographic hashing function or algorithmcan be applied to the unique asset identifier of the asset such as theasset token that itself was obtained via an application of a hashingfunction on the identifying parameters of the non-fungible asset, asdiscussed in the example above. Further, to encode some aspects of theownership of the asset, in some implementations, the cryptographichashing function can also be applied to a public identifier on theZKP-enabled DLN 100 that is associated with the owner (e.g., sender 110a when the sender 110 a is minting the token commitment for the firsttime). An example of such public identifier includes the public key ofthe sender on the ZKP-enabled DLN 100 (i.e., the public key that isassociated with the sender 110 a on the ZKP-enabled DLN 100).

In some embodiments, the cryptographic hashing function can also beapplied to a random nonce such as, but not limited to, a random orserial number that is securely generated and used, at least in mostcases, only once. In some implementations, the random nonce can be usedas a handle of the non-fungible token commitment independent of thenon-fungible asset (e.g., encoded by the asset token) and/or itsownership (e.g., encoded by the public key). For example, as discussedbelow, the transfer of a physical asset to the recipient 110 b can berepresented by the generation and registration on the ZKP-enabled DLN100 of a new token commitment that associates the asset with the newowner, the recipient 110 b, and the nullification of the existing tokencommitment that associated the asset with the sender 110 a. In suchimplementations, the token commitment handle, the random nonce, can beused to nullify the existing token commitment, as discussed below.

In some embodiments, the minting of a non-fungible token commitment torepresent an asset ZKP-enabled DLN 100 for the first time may includethe computation of a token commitment (Z-token) as follows: Z=H(S

P_(k)

A), where A is the asset token identifying the asset (e.g., obtained byhashing, off-chain, at least some identifying parameters of the asset),P_(k) is the public key on the blockchain that is associated with thesender 110 a (i.e., the current owner of the asset), S is a randomnonce, H is a cryptographic hashing function or algorithm (e.g.,SHA-256), and

represents a combining operator (e.g., the XOR operator ⊕, theconcatenation operator |, etc.). In some embodiments, the computation ofthe token commitment Z may include application of the hashing functionon additional elements besides or instead of S, P_(k) and A. In someembodiments, the token commitment comprises or consists of a randomnonce (e.g., a securely and randomly generated serial number), a publicidentifier on the ZKP-enabled DLN 100 of the sender 110 a (e.g., publickey of the sender 110 a) and an asset identifier (e.g., asset token A).In some embodiments, the application of the hashing function incomputing for the Z-token (i.e., token commitment) allows for thegeneration or construction of the non-fungible token (e.g., Z-token ortoken commitment) without revealing the identities of the random nonce Sand/or the asset token A on the ZKP-enabled DLN 100 (i.e., S and A maybe kept secret by the sender 110 a, except when A is transmitted(privately) to the recipient 110 b as discussed below during an assettransfer transaction).

After the token commitment is computed, at 208, the sender 110 a mayprovide or publish, anonymously and using the computing node 102 a, theZ-token and/or a hash of the asset token A, H(A), to a self-executingcode or smart contract on the ZKP-enabled DLN 100 to have the tokencommitment (i.e., Z-token) minted or registered for the first time onthe ZKP-enabled DLN 100. Prior to the Z-token being included in thedistributed ledgers 104 a-104 e of the ZKP-enabled DLN 100 as arepresentation of the off-chain asset (e.g., vehicle asset 112) on theZKP-enabled DLN 100, however, the sender 110 a may have to demonstrateto the ZKP-enabled DLN 100 that (1) the Z-token in fact includes theasset token A, and/or (2) the asset is not already represented on theZKP-enabled DLN 100, i.e., a Z-token is not already minted for the asseton the ZKP-enabled DLN 100 (e.g., to avoid “double minting,” which canlead to undesirable “double spend” or “double transfer” on theZKP-enabled DLN 100 of multiple token commitments all representing thesame asset), according to some embodiments. In some implementations, thesender 110 a may generate and provide anonymously to the smart contract,using the computing node 102 a, a ZKP that the Z-token includes theasset token A. Further, the ZKP may also include a proof that a hash ofthe asset token A, H(A), includes the asset token A. In someimplementations, the hash H(A) can be used by the smart contract toverify that the asset is not already represented on the ZKP-enabled DLN100. That is, as discussed below, H(A) can be used to preventundesirable “double spend” by prohibiting a future attempt to mint orregister a new token commitment for the asset identified off-chain bythe asset token A while another valid token commitment for the sameasset (i.e., the asset identified by the asset token A) exists on theZKP-enabled DLN 100. In other words, in some embodiments, H(A) can beused to prevent the minting of a new token commitment if there is anexisting token commitment representing, on the ZKP-enabled DLN 100, theasset identified off-chain by the asset token A.

In some embodiments, if a token commitment (Z-token) representing theasset (as identified by the asset token A) already exists on theZKP-enabled DLN 100, then a new token commitment Z′ representing thesame asset can be generated on the ZKP-enabled DLN 100 only upon thenullification or invalidation of the existing token commitment Z, asdiscussed below (by nullified or invalidated, in some embodiments, it ismeant, without limitations, that the existing token commitment is nolonger valid to represent the asset on the DLN 100 (e.g., the smartcontract would reject the token commitment if it were provided to it asa representation of the asset)).

In some embodiments, the sender 110 a, using the computing node 102 a,provides the ZKP to the smart contract without having revealed A to theZKP-enabled DLN 100 (i.e., without exposing A to the participants of theblockchain), thereby protecting the identity of the physical asset beingtransacted between the sender 110 a and the recipient 110 b. The hashingof the asset token A also allows the sender 110 a to hide the identityof the asset token A (and hence the asset itself) from the ZKP-enabledDLN 100 or the smart contract (and hence from the other participants onthe ZKP-enabled DLN 100).

Upon receiving the token commitment Z, the hash of the asset token H(A),and/or the ZKPs, in some embodiments, the self-executing code or smartcontract may verify the ZKPs. For example, the smart contract may obtainor retrieve a public input and/or a verification key (e.g., from thesender 110 a) and compute the ZKPs to verify statements included in theZKPs, such as the statements that H(A) includes A (i.e., the statementthat H(A) is obtained by applying a hashing function or algorithm on theasset token A) and the statement that the token commitment Z alsoincludes A (i.e., the statement that Z is obtained by applying a hashingfunction or algorithm on the asset token A). Further, the smart contractmay verify that there has never been an H(A) provided to the smartcontract previously (e.g., if the asset has never been represented onthe ZKP-enabled DLN 100). For example, at 210, the ZKP-enabled DLN 100may include a double-spend preventer data structure that includes allthe hashes of asset tokens that have been provided to the smart contractpreviously. In such embodiments, the smart contract may check thedouble-spend preventer data structure for the presence of a hash of theasset token A, and if there is one, this may be understood as the assetidentified off-chain by the asset token A has already been minted orregistered on the ZKP-enabled DLN 100, and as such, the smart contractmay reject the token commitment Z provided by the sender 110 a, andprevent its inclusion into a commitments data structure on theZKP-enabled DLN 100. In some embodiments, the commitments data structureincludes token commitments (e.g., a token commitment such as the Z-tokenZ=H(S

P_(k)

A) that serve as a representation, on the ZKP-enabled DLN 100, of anasset identified by the asset token A), the token commitment Z havingbeen included into the commitments data structure after the smartcontract verifies that the double-spend preventer data structure doesnot contain the hashes of the asset tokens (e.g., after the smartcontract verifies that H(A) is not included in the double-spendpreventer data structure). As such, the double-spend preventer datastructure can be used to prevent the undesirable problem of “doublespend,” where a user of the ZKP-enabled DLN 100 may mint or generate two(or in general, multiple) token commitments Z_(n)=H(S_(n)

P_(k)

A) for a single asset identified by A, and attempt to transfer the two(or multiple) Z_(n) to different entities (which is what a “doublespend” is, since there is only a single underlying asset for themultiple transfers). Once there is a H(A) in the double-spend preventerdata structure, in some implementations, the smart contract would notallow adding, into the commitments data structure, a new tokencommitment representing the asset identified by the asset token A. Thatis, the smart contract would not allow the minting of a new tokencommitment Z=H(S

P_(k)

A) for an asset identified by the asset token A if H(A) is present inthe double-spend preventer data structure. In some embodiments, thedouble-spend preventer data structure and/or the commitments datastructure may be stored on the ZKP-enabled DLN 100 (i.e., these datastructures may be stored on storage systems that are linked to or partof the computing nodes 102 a-102 e that make up the ZKP-enabled DLN100). As noted above, the combining operator

may include the XOR operator ⊕, the concatenation operator |, and/or thelike.

In some embodiments, the smart contract may discover that the hash ofthe asset token A, H(A), is not in the double-spend preventer datastructure. In such embodiments, the smart contract may add H(A) intodouble-spend preventer data structure and allow the addition of thetoken commitment into the commitments data structure on the ZKP-enabledDLN 100. The addition of the token commitment into the commitments datastructure, at 212, may signify the representation or registration of theasset on the ZKP-enabled DLN 100. Further, since the token commitmentincludes an identifier (e.g., a public identifier) of the sender 110 aon the ZKP-enabled DLN 100 (e.g., public key of the sender 110 a), insome implementations, the token commitment also serves as a notice or arecord of the ownership of the asset (e.g., ownership belonging to theentity that is behind the public key on the ZKP-enabled DLN 100, i.e.,the sender 110 a). It is to be noted, however, that, in someembodiments, other participants on the ZKP-enabled DLN 100 100 may notbe privy to A (i.e., the identity of the asset being transacted) and/orthe owner/sender 110 a of the asset. That is, the privacy of the sender110 a (as it related to ownership and the identity of the asset, forexample) can be protected as a result of the use of ZKP in the methodsand systems disclosed herein.

FIG. 3 shows a flow chart illustrating the generation of new tokencommitment on the distributed ledger to represent the transfer of areal-world or physical asset from a sender to a recipient, according tosome embodiment. At 302, the new token commitment may be generated inresponse to a request to represent the asset transfer on the ZKP-enabledDLN 100. Once the asset 112 (e.g., non-fungible asset) is represented onthe ZKP-enabled DLN 100 as discussed above, at 304, the transfer of theasset 112 from the sender 110 a to the recipient 110 b can berepresented on the ZKP-enabled DLN 100 by the generation of a newnon-fungible token commitment that is linked or associated with therecipient 110 b, and the nullification or invalidation of the existingtoken commitment Z that included the identifier (e.g., public key) ofsender 110 a. For example, the new non-fungible token commitment (the“recipient token commitment”) can be generated by an application of ahashing function or algorithm on an identifier (e.g., public identifier)of the recipient 110 b, an example of such identifier including thepublic key of the recipient on the ZKP-enabled DLN 100. Further, sincethe recipient token commitment should represent the same off-chain asset112 as the existing token commitment (the “sender token commitment”,which was obtained by an application of a hashing function on the assettoken A), in some implementations, the application of the hashingfunction to obtain the recipient token commitment may also includeapplying the hashing function on the same asset token A. In addition, insome implementations, the hashing function may also be applied on arandom nonce for reasons discussed above with reference to thecomputation of the sender token commitment. In some implementations, therandom nonce used to generate the sender token commitment Z may bedifferent from the random nonce that would be used to generate therecipient token commitment.

An example implementation of the generation of a non-fungible recipienttoken commitment as discussed above can include the computation of arecipient Z′-token as follows: Z′=H(S′

P_(k)′

A), where A is the asset token used in generating the sender tokencommitment Z, P_(k)′ is the public key on the ZKP-enabled DLN 100 thatis associated with the recipient 110 b, S′ is a random nonce, H is acryptographic hashing function or algorithm (e.g., SHA-256), and

represents a combining operator (e.g., the XOR operator ⊕, theconcatenation operator |, etc.). In some embodiments, S′ may bedifferent from S. In some embodiments, the computation of the recipienttoken commitment Z′ may include application of the hashing function onadditional elements besides or instead of S′, P_(k)′ and A. In someembodiments, the recipient token commitment Z′ may comprise or consistS′, P_(k)′ and A. In some embodiments, the recipient token commitment Z′may be generated by the sender 110 a and provided, via the computingnode 102 a, to the smart contract of the ZKP-enabled DLN 100anonymously. Further, the sender 110 a may secretly provide therecipient 110 b the random nonce S′ and/or the asset token A (i.e.,without divulging or revealing S′ and/or A ZKP-enabled DLN 100 (i.e., tothe public or the other participants of the ZKP-enabled DLN 100)).

Before the smart contract can allow the addition of the recipient tokencommitment Z′ onto the commitments data structure, thereby passing therepresentation of the ownership of the asset 112 on the ZKP-enabled DLN100 from the sender 110 a to the recipient 110 b, in some embodiments,the sender 110 a may have to demonstrate to the smart contract that theZ token (i.e., the sender token commitment) belongs to the sender 110 a(signifying that the asset 112 belongs to the sender 110 a). Further,the sender 110 a would have to demonstrate to the smart contract that anew token commitment, the recipient token commitment Z′, representingthe same asset 112 but assigning ownership to the recipient 110 b, hasbeen generated and that the sender token commitment, which is already onthe commitments data structure, has been nullified or invalidated. Thesevarious demonstrations are described below.

In some embodiments, to demonstrate to the smart contract that thesender token commitment Z belongs to the sender 110 a, the sender 110 acan provide the smart contract anonymously a ZKP that the sender 110 aknows that the token commitment Z is obtained by an application of ahashing function on a combination of a random nonce, an asset identifierof the off-chain asset that is being transacted and/or an identifierassociated with the sender 110 a on the ZKP-enabled DLN 100 such as butnot limited to a public identifier. For example, the ZKP can include aproof that the sender 110 a has knowledge that Z is obtained by applyinga hashing function or algorithm on a combination of a random nonce S, anasset token A that can be used as an identifier of the asset 112, and/orthe public key of the sender 110 a on the ZKP-enabled DLN 100. As aspecific example, the ZKP can include a proof that Z is obtained by thecomputation H(S

P_(k)

A), where the combining operator

may include the XOR operator ⊕, the concatenation operator |, and/or thelike.

In some embodiments, providing a proof that the sender 110 a knows thatthe token commitment Z is obtained by an application of a hashingfunction on a combination of a random nonce, an asset identifier of theoff-chain asset and/or an identifier associated with the sender 110 a onthe blockchain may not be sufficient as a proof that the sender tokencommitment Z belongs to the sender 110 a, since there could be otherparticipants of the ZKP-enabled DLN 100 that can have the statedinformation. For example, in some embodiments, the asset 112 may nothave been minted or represented on the ZKP-enabled DLN 100 initially bythe sender 110 a, but rather by a prior owner or sender (not shown) thatthen transferred the asset to the sender 110 a. In such cases, the priorsender may have been the one that generated the asset token A(off-chain, for example) and represented the transfer of the asset 112from the prior sender to the sender 110 a on the ZKP-enabled DLN 100 byhaving the smart contract on the ZKP-enabled DLN 100 add the tokencommitment Z=H(S

P_(k)

A) to the token commitments data structure, where P_(k) is the publickey of the sender 110 a that is receiving the asset 112 from the priorowner. In such embodiments, the prior owner would have knowledge orpossession of S, P_(k) and/or A, and as such can generate similar orsame ZKP as one generated by the sender 110 a and provided to the smartcontract to represent the transfer of the asset to the recipient 110 b.As such, to demonstrate that the sender 110 a is the rightful (e.g.,current) owner of the asset, in some implementations, the sender 110 amay also provide to the smart contract, via the computing node 102 a, aZKP that the sender 110 a can generate the public identifier associatedwith the sender 110 a on the ZKP-enabled DLN 100 from a correspondingsecret identifier associated with the sender 110 a on the ZKP-enabledDLN 100. For example, the public identifier associated with the sender110 a can be the public key of the sender 110 a, and the sender 110 acan provide the smart contract a ZKP that the sender 110 a can derive orobtain the public key P_(k) from the private key V_(k) of the sender 110a. As the private key V_(k) is known only to the sender 110 a, at leastnominally, in such implementations, the prior sender or any other partyor participant of the ZKP-enabled DLN 100 may not be able to generatesuch ZKP. As such, in some embodiments, the sender's claim that thesender token commitment Z belongs to the sender 110 a may be proved byverifying the ZKP, generated and provided to the smart contract by thesender 110 a, that the sender 110 a has knowledge that Z can be obtainedby computing H(S

P_(k)

A) and that P_(k) can be obtained from V_(k).

In some embodiments, the sender 110 a may also have to demonstrate tothe smart contract that the sender token commitment Z is no longer validbefore the smart contract can allow the addition of the recipient tokencommitment Z′ onto the commitments data structure. The smart contractmay enforce this condition to avoid a “double-spend” by the sender 110a, where the sender 110 a can generate a plurality of token commitmentsfor the same off-chain asset 112 using the same asset token A butdifferent random nonces S and different public keys of otherparticipants 110 c-110 e in the ZKP-enabled DLN 100. In someembodiments, “double spend” by the sender 110 a can be prevented byhaving the sender 110 a generate and provide to the smart contract, viathe computing node 102 a, a nullifier that nullifies the sender tokencommitment that is already on the token commitments data structure. Byrequiring the sender 110 a to nullify an existing valid token commitmentZ (i.e., a token commitment that is stored in the token commitments datastructure) prior to the addition of a new token commitment Z′ into thetoken commitments data structure, in some implementations, the smartcontract prevents the “double spend” problem, since the sender 110 a cannullify Z only once (hence only one Z′ can be added into the commitmentsdata structure, i.e., no “double spend”).

In some embodiments, the nullifier can be constructed or generated outof the random nonce S that was used to generate the token commitment Z.The random nonce S, however, may be known to other participants of theZKP-enabled DLN 100 (i.e., besides the sender 110 a), such as a previousowner of the asset. To demonstrate to the smart contract that thenullifier is in fact constructed or generated by the sender 110 a (andnot by a previous owner of the asset 112, for example), in someembodiments, the sender 110 a may include in the nullifier a secretelement or identifier that is known only to the sender 110 a. Forexample, in some embodiments, the nullifier can be computed via anapplication of a hashing function H on the random nonce S and theprivate key of the sender 110 a, V_(k), as follows: N=H(S

V_(k)), where the combining operator

may include the XOR operator ⊕, the concatenation operator |, and/or thelike.

At 306, the sender 110 a may provide the nullifier N to the smartcontract, via the computing node 102 a, along with a ZKP that the sender110 a knows N is obtained via an application of the hashing function Hon the random nonce S and the private key V_(k). In someimplementations, the hashing allows the sender 110 a to hide theidentity of the random nonce S and/or the private key V_(k), and the ZKPallows the sender 110 a to convince the smart contract, if the proof isverified, that N includes S and V_(k), without the sender 110 a havingto reveal S and V_(k) themselves to the smart contract or theparticipants of the blockchain 100. In some embodiments, the ZKP-enabledDLN 100 may include a nullifier data structure that includes all thenullifiers that have been provided to the smart contract. For example,the nullifier data structure may be stored on the ZKP-enabled DLN 100(i.e., the data structure may be stored on storage systems that arelinked to or part of the computing nodes 102 a-102 e that make up theZKP-enabled DLN 100). In such embodiments, the smart contract may checkto see if the nullifier N provided by the sender 110 a is alreadypresent in the nullifier data structure, and if so, may reject theaddition of the recipient token commitment Z′ onto the commitments datastructure as the presence of N in the nullifier data structure indicatesthat the sender token commitment Z has already been nullified (whichindicates that the sender 110 a does not own the asset 112, and as suchcannot be in the position to transfer the asset 112 to the recipient 110b).

Before the smart contract can allow the addition of the recipient tokencommitment Z′ onto the commitments data structure, in some embodiments,the sender 110 a may also have to demonstrate to the smart contract thatthe recipient token commitment Z′ includes an identifier associated withthe recipient (e.g., a public identifier such as the public key P_(k)′of the recipient), an identifier that can be used to identify the asset(e.g., the asset token A) and/or the random nonce S′. To accomplish thisgoal without revealing identifying information about the public keyP_(k)′, the asset token A and/or the random nonce S′ on the ZKP-enabledDLN 100, at 308, the sender 110 a may generate and provide to the smartcontract, via the computing node 102 a, a ZKP that Z′ includes, or isgenerated using, the identifier associated with the recipient (e.g., thepublic key P_(k)′ of the recipient), the asset identifier (e.g., theasset token A) and/or the random nonce S′. In particular, the ZKPincludes the proof that the asset token in the recipient tokencommitment Z′ is the same asset token as the asset token in the sendertoken commitment Z, which demonstrates to the smart contract, whenverified, that the sender token commitment Z and the recipient tokencommitment Z′ represent the same asset on the ZKP-enabled DLN 100 thatis being transacted between the sender 110 a and the recipient 110 b.

Upon receiving the above-identified ZKPs, in some embodiments, the smartcontract may verify the ZKPs and/or check that the nullifier N is notalready included in the nullifier data structure of the ZKP-enabled DLN100. As N is configured to nullify the sender token commitment Z uponaddition onto the nullifier data structure, in some implementations, itsprior presence on nullifier data structure would indicate that Z hasalready been nullified, which would cause the smart contract to rejectthe addition of the recipient token commitment Z′ onto the commitmentsdata structure. In some embodiments, upon verifying that the nullifier Nis not included in the nullifier data structure, the smart contract mayadd the nullifier into the nullifier data structure (after all the ZKPsare verified, for example).

As discussed above, the ZKPs provided by the sender 110 a include (a)the ZKP that the nullifier N is obtained via an application of a hashingfunction or algorithm on a random nonce and/or a private key on theZKP-enabled DLN 100 of the sender 110 a, (b) the ZKP that the sendertoken commitment Z is obtained via an application of a hashing functionon the same random nonce used in generating the nullifier, a publicidentifier on the ZKP-enabled DLN 100 of the sender 110 a (e.g., thepublic key of the sender 110 a) and/or the asset token, (c) the ZKP thatthe sender 110 a can generate or derive the public identifier associatedwith the sender 110 a from a secret identifier associated with thesender 110 a (e.g., the sender 110 a can derive its public key from itsprivate key), and/or the (d) ZKP that the recipient token commitment Z′is obtained via an application of a hashing function on a random nonce(e.g., different from the random nonce used to generate Z), a publicidentifier on the ZKP-enabled DLN 100 of the recipient 110 b (e.g., thepublic key of the recipient 110 b) and/or the same asset token used ingenerating or computing the sender token commitment Z. After verifyingone or more of the above-identified ZKPs, at 310, the smart contract mayallow the recipient token commitment Z′ to be added onto the commitmentsdata structure of the ZKP-enabled DLN 100, which signifies therepresentation, on the ZKP-enabled DLN 100, of the transfer of the asset112 from the sender 110 a to the recipient 110 b.

In some embodiments, if the recipient 110 b wishes to transfer the asset112 to another participant 110 c after receiving it from the sender 110a, the recipient 110 b can carry out all or nearly all the same stepsundertaken by the sender 110 a to represent the transfer transaction onthe ZKP-enabled DLN 100 between the sender 110 a and the recipient 110b. The recipient 110 b may not, however, be able to generate an assettoken to identify the asset 112, as the presence of the hash of theasset token H(A) in the preventer data structure would cause the smartcontract to reject the token commitments the recipient 110 b would haveto provide to the smart contract to represent the transfer of the assetto the new recipient 110 c. As such, once an asset is minted on theblockchain 100 for the first time (and identified with an asset tokenA), it cannot be minted again, but can only be transferred from oneparticipant of the ZKP-enabled DLN 100 to another via the generation ofa token commitment that includes the same asset token A that was createdduring the initial minting or representation of the asset 112 on theZKP-enabled DLN 100. As such, the double-spend preventer data structurecan be used to prevent “double-spend,” where multiple token commitmentsZ are created for the same asset 112, and are transferred to a pluralityof participants.

As discussed above, with the use of ZKPs, a sender 110 a can representon the ZKP-enabled DLN 100 a physical, off-chain asset 112, withouthaving to disclose or reveal to other participants of the ZKP-enabledDLN 100 (or to the public) any identifying information about the asset112 (e.g., without revealing asset token A obtained by hashingidentifying parameters of the asset 112 such as serial numbers, modelnumbers, asset name, etc.). Further, the identity of the sender 110 acan also remain hidden from the blockchain 100. For example, in mintinga token commitment Z on the ZKP-enabled DLN 100 for the asset 112, thesender 110 a provides to the smart contract anonymously a hash of A,H(A), and Z=H(S

P_(k)

A), which conceal or cloak the identity of the sender 110 a, the randomnonce S, the public key P_(k), the serial token A (which can be obtainedby hashing some identifying information of the asset 112), etc. Thesmart contract can verify the provided ZKPs, and allow the tokencommitment Z to be added onto the token commitments data structure,without having access to any of these information (including theidentity of the sender 110 a, as H(A) and Z are provided by the sender110 a anonymously). As such, the use of ZKPs in the ZKP-enabled DLN 100allows for the representation of an asset 112 on the ZKP-enabled DLN 100while preserving the confidentiality or privacy of participants or usersof the ZKP-enabled DLN 100 (such as sender 110 a) and their assets (suchas the vehicle 112).

Further, the use of ZKPs also allows participants to represent, on theZKP-enabled DLN 100, their off-chain asset 112 transactions withoutrevealing or exposing the transaction participants as well as details ofthe transaction itself on the ZKP-enabled DLN 100 (i.e., to the otherparticipants of the ZKP-enabled DLN 100, which may include the generalpublic). As noted above, the sender 110 a provides to the smart contractanonymously (and hence hidden from at least the other participants 110c-110 e) the sender token commitment Z=H(S

P_(k)

A), the recipient token commitment Z′=H(S′

P_(k)′

A) and the nullifier N=H(S

S_(k)), without revealing S, P_(k), S′, P_(k)′, A and/or S_(k), therebyprotecting the identities of the sender 110 a, the recipient 110 band/or the asset identified by A. As noted above, the combining operator

may include the XOR operator ⊕, the concatenation operator |, and/or thelike. In some implementations, the identity of the sender 110 a can beprotected as the sender 110 a communicates with the smart contractanonymously. The smart contract can, without having access to any ofthese information, verify the provided ZKPs and allow (i) the additionof the recipient token commitment Z′ onto the token commitments datastructure and (ii) the nullification of the sender token commitment Z.As such, the use of ZKPs in the on the ZKP-enabled DLN 100 allows forthe representation of a transaction including the transfer of the asset112 on the blockchain while preserving the confidentiality or privacy ofthe participants of the transaction (such as sender 110 a and recipient110 b) as well as the assets (such as the vehicle 112) and thetransaction itself (e.g., random nonces, asset tokens, etc. generatedduring the transaction).

Some embodiments of the current disclosure include a method comprising:sending a request to cause an asset identifiable by an identifyingparameter be registered on a distributed ledger-based network (DLN); andreceiving, in response to the request, a confirmation confirming theregistration of the asset on the DLN, the confirmation being issuedafter verification of a zero-knowledge proof (ZKP), provided by aprover, that the prover has knowledge of an identity of an asset tokenthat when a hashing function is applied to the asset token, a tokencommitment representing the asset on the DLN is generated.

In some embodiments, the hashing function is a first hashing function;and the asset token is obtained via an application of a second hashingfunction on the identifying parameter of the asset.

In some embodiments, the hashing function is a first hashing function;the ZKP includes the ZKP that the prover of the ZKP has knowledge of theidentity of the asset token that when a second hashing function isapplied to the asset token, a first hash value is generated; theverification of the ZKP includes verifying that the first hash value isnot stored in a double-spend preventer data structure on the DLN priorto the issuance of the confirmation.

In some embodiments, the hashing function is a first hashing function;the ZKP includes the ZKP that the prover of the ZKP has knowledge of theidentity of the asset token that when a second hashing function isapplied to the asset token, a first hash value is generated; theconfirmation is issued after the first hash value is added onto adouble-spend preventer data structure on the DLN after a verificationthat the first hash value is not stored in the double-spend preventerdata structure.

In some embodiments, the application of the hashing function includesthe application of the hashing function on an identifier associated withan owner of the token commitment and/or a random nonce, the identifierincluding a public key of the owner on the DLN.

In some embodiments, the ZKP and/or the verification of the ZKP do notreveal the identifying parameter of the asset and/or a random nonce usedto generate the token commitment on the DLN.

In some embodiments, the confirmation is issued without revealing anyidentifying information of the asset, an owner of the asset, and/or arandom nonce used to generate the token commitment on the DLN.

Some embodiments of the current disclosure include a method comprising:receiving a request that is configured to cause a transfer of an assetfrom a sender to a recipient, the asset represented on a distributedledger-based network (DLN) by a first token commitment; and causing, inresponse to the request and on the DLN, a registration of the transferof the asset from the sender to the recipient, the registrationoccurring after verification of a zero-knowledge proof (ZKP), providedby a prover, that the prover has knowledge of an identity of an assettoken, (1) the first token commitment obtained via an application of afirst hashing function on the asset token, and/or (2) a second tokencommitment representing the asset on the DLN obtained via an applicationof a second hashing function on the asset token.

In some embodiments, the ZKP includes the ZKP that the prover hasknowledge of an identity of: (a) a first identifier associated with thesender, the first token commitment obtained via the application of thefirst hashing function on the first identifier, and/or (b) a secondidentifier associated with the recipient, the second token commitmentobtained via the application of the second hashing function on thesecond identifier.

In some embodiments, the ZKP includes the ZKP that the prover hasknowledge of an identity of: (a) a first identifier associated with thesender, the first token commitment obtained via the application of thefirst hashing function on the first identifier, the first identifierincluding a public key of the sender on the DLN, and/or (b) a secondidentifier associated with the recipient, the second token commitmentobtained via the application of the second hashing function on thesecond identifier, the second identifier including a public key of therecipient on the DLN.

In some embodiments, the ZKP includes the ZKP that the prover is capableof deriving a first identifier associated with the sender from a secretidentifier associated with the sender, the first identifier and thesecret identifier including a public key and a private key,respectively, of the sender on the DLN.

In some embodiments, the registration of the transfer occurs after averification that a nullifier is not stored in a nullifier datastructure on the DLN, a presence of the nullifier in the nullifier datastructure indicating invalidity of the first token commitment.

In some embodiments, the registration of the transfer occurs after anullifier is added into a nullifier data structure on the DLN after averification that the nullifier is not stored in the nullifier datastructure, a presence of the nullifier in the nullifier data structureindicating invalidity of the first token commitment.

In some embodiments, the ZKP includes the ZKP that the prover hasknowledge of an identity of a nullifier obtained via an application of athird hashing function on a random nonce and/or a secret identifierassociated with the sender, a presence of the nullifier in a nullifierdata structure on the DLN indicating invalidity of the first tokencommitment.

In some embodiments, the ZKP includes the ZKP that the prover hasknowledge of an identity of a nullifier obtained via an application of athird hashing function on a random nonce and/or a secret identifierassociated with the sender, a presence of the nullifier in a nullifierdata structure on the DLN indicating invalidity of the first tokencommitment, the application of the first hashing function including theapplication of the first hashing function on the random nonce.

In some embodiments, the ZKP includes the ZKP that the prover hasknowledge of an identity of a nullifier obtained via an application of athird hashing function on a random nonce and/or a secret identifierassociated with the sender, a presence of the nullifier in a nullifierdata structure on the DLN indicating invalidity of the first tokencommitment, the secret identifier including the private key of thesender.

In some embodiments, the verification of the ZKP occurs without anyidentifying information of the asset including the identifying parameterof the asset being revealed on the DLN.

In some embodiments, the verification of the ZKP occurs without anyidentifying information of the sender and/or the recipient beingrevealed, the identifying information of the sender and/or the recipientincluding a public key of the sender, a private key of the sender, apublic key of the recipient and/or a private key of the recipient, onthe DLN.

In some embodiments, the verification of the ZKP occurs without anyidentifying information of the first token commitment and/or a randomnonce being revealed on the DLN.

While various embodiments have been described and illustrated herein,one will readily envision a variety of other means and/or structures forperforming the function and/or obtaining the results and/or one or moreof the advantages described herein, and each of such variations and/ormodifications is deemed to be within the scope of the embodimentsdescribed herein. More generally, one will readily appreciate that allparameters, dimensions, materials, and configurations described hereinare meant to be exemplary and that the actual parameters, dimensions,materials, and/or configurations will depend upon the specificapplication or applications for which the teachings is/are used. Onewill recognize, or be able to ascertain using no more than routineexperimentation, many equivalents to the specific embodiments describedherein. It is, therefore, to be understood that the foregoingembodiments are presented by way of example only and that, within thescope of the disclosure, including the appended claims and equivalentsthereto, disclosed embodiments may be practiced otherwise than asspecifically described and claimed. Embodiments of the presentdisclosure are directed to each individual feature, system, tool,element, component, and/or method described herein. In addition, anycombination of two or more such features, systems, articles, elements,components, and/or methods, if such features, systems, articles,elements, components, and/or methods are not mutually inconsistent, isincluded within the scope of the present disclosure.

The above-described embodiments can be implemented in any of numerousways. For example, embodiments may be implemented using hardware,software or a combination thereof. When implemented in software, thesoftware code can be stored (e.g., on non-transitory memory) andexecuted on any suitable processor or collection of processors, whetherprovided in a single computer or distributed among multiple computers.

Further, it should be appreciated that a computer may be embodied in anyof a number of forms, such as a rack-mounted computer, a desktopcomputer, a laptop computer, netbook computer, or a tablet computer.Additionally, a computer may be embedded in a device not generallyregarded as a computer but with suitable processing capabilities,including a smart phone, smart device, or any other suitable portable orfixed electronic device.

Also, a computer can have one or more input and output devices. Thesedevices can be used, among other things, to present a user interface.Examples of output devices that can be used to provide a user interfaceinclude printers or display screens for visual presentation of outputand speakers or other sound generating devices for audible presentationof output. Examples of input devices that can be used for a userinterface include keyboards, and pointing devices, such as mice, touchpads, and digitizing tablets. As another example, a computer can receiveinput information through speech recognition or in other audible format.

Such computers can be interconnected by one or more networks in anysuitable form, including a local area network or a wide area network,such as an enterprise network, and intelligent network (IN) or theInternet. Such networks can be based on any suitable technology and canoperate according to any suitable protocol and can include wirelessnetworks, wired networks or fiber optic networks.

The various methods or processes outlined herein can be coded assoftware that is executable on one or more processors that employ anyone of a variety of operating systems or platforms. Additionally, suchsoftware can be written using any of a number of suitable programminglanguages and/or programming or scripting tools, and also can becompiled as executable machine language code or intermediate code thatis executed on a framework or virtual machine.

In this respect, various disclosed concepts can be embodied as acomputer readable storage medium (or multiple computer readable storagemedia) (e.g., a computer memory, one or more floppy discs, compactdiscs, optical discs, magnetic tapes, flash memories, circuitconfigurations in Field Programmable Gate Arrays or other semiconductordevices, or other non-transitory medium or tangible computer storagemedium) encoded with one or more programs that, when executed on one ormore computers or other processors, perform methods that implement thevarious embodiments of the disclosure discussed above. The computerreadable medium or media can be transportable, such that the program orprograms stored thereon can be loaded onto one or more differentcomputers or other processors to implement various aspects of thepresent disclosure as discussed above.

The terms “program” or “software” are used herein in a generic sense torefer to any type of computer code or set of computer-executableinstructions that can be employed to program a computer or otherprocessor to implement various aspects of embodiments as discussedabove. Additionally, it should be appreciated that according to oneaspect, one or more computer programs that when executed perform methodsof the present disclosure need not reside on a single computer orprocessor, but can be distributed in a modular fashion amongst a numberof different computers or processors to implement various aspects of thedisclosure.

Computer-executable instructions can be in many forms, such as programmodules, executed by one or more computers or other devices. Generally,program modules include routines, programs, objects, components, datastructures, etc. that perform particular tasks or implement particularabstract data types. Typically the functionality of the program modulescan be combined or distributed as desired in various embodiments.

Also, data structures can be stored in computer-readable media in anysuitable form. For simplicity of illustration, data structures may beshown to have fields that are related through location in the datastructure. Such relationships can likewise be achieved by assigningstorage for the fields with locations in a computer-readable medium thatconvey relationship between the fields. However, any suitable mechanismcan be used to establish a relationship between information in fields ofa data structure, including through the use of pointers, tags or othermechanisms that establish relationship between data elements.

Also, various concepts can be embodied as one or more methods, of whichan example has been provided. The acts performed as part of the methodmay be ordered in any suitable way. Accordingly, embodiments can beconstructed in which acts are performed in an order different thanillustrated, which can include performing some acts simultaneously, eventhough shown as sequential acts in illustrative embodiments. Allpublications, patent applications, patents, and other referencesmentioned herein are incorporated by reference in their entirety.

All definitions, as defined and used herein, should be understood tocontrol over dictionary definitions, definitions in documentsincorporated by reference, and/or ordinary meanings of the definedterms.

The indefinite articles “a” and “an,” as used herein in thespecification and in the claims, unless clearly indicated to thecontrary, should be understood to mean “at least one.”

The phrase “and/or,” as used herein in the specification and in theclaims, should be understood to mean “either or both” of the elements soconjoined, i.e., elements that are conjunctively present in some casesand disjunctively present in other cases. Multiple elements listed with“and/or” should be construed in the same fashion, i.e., “one or more” ofthe elements so conjoined. Other elements may optionally be presentother than the elements specifically identified by the “and/or” clause,whether related or unrelated to those elements specifically identified.Thus, as a non-limiting example, a reference to “A and/or B”, when usedin conjunction with open-ended language such as “comprising” can refer,in one embodiment, to A only (optionally including elements other thanB); in another embodiment, to B only (optionally including elementsother than A); in yet another embodiment, to both A and B (optionallyincluding other elements); etc.

As used herein, “or” should be understood to have the same meaning as“and/or” as defined above. For example, when separating items in a list,“or” or “and/or” shall be interpreted as being inclusive, i.e., theinclusion of at least one, but also including more than one, of a numberor list of elements, and, optionally, additional unlisted items. Onlyterms clearly indicated to the contrary, such as “only one of” or“exactly one of,” or, when used in claims, “consisting of,” will referto the inclusion of exactly one element of a number or list of elements.In general, the term “or” as used herein shall only be interpreted asindicating exclusive alternatives (i.e. “one or the other but not both”)when preceded by terms of exclusivity, such as “either,” “one of,” “onlyone of,” or “exactly one of” “Consisting essentially of,” when used inclaims, shall have its ordinary meaning as used in the field of patentlaw.

As used herein, the phrase “at least one,” in reference to a list of oneor more elements, should be understood to mean at least one elementselected from any one or more of the elements in the list of elements,but not necessarily including at least one of each and every elementspecifically listed within the list of elements and not excluding anycombinations of elements in the list of elements. This definition alsoallows that elements may optionally be present other than the elementsspecifically identified within the list of elements to which the phrase“at least one” refers, whether related or unrelated to those elementsspecifically identified. Thus, as a non-limiting example, “at least oneof A and B” (or, equivalently, “at least one of A or B,” or,equivalently “at least one of A and/or B”) can refer, in one embodiment,to at least one, optionally including more than one, A, with no Bpresent (and optionally including elements other than B); in anotherembodiment, to at least one, optionally including more than one, B, withno A present (and optionally including elements other than A); in yetanother embodiment, to at least one, optionally including more than one,A, and at least one, optionally including more than one, B (andoptionally including other elements); etc.

All transitional phrases such as “comprising,” “including,” “carrying,”“having,” “containing,” “involving,” “holding,” “composed of,” and thelike are to be understood to be open-ended, i.e., to mean including butnot limited to. Only the transitional phrases “consisting of” and“consisting essentially of” shall be closed or semi-closed transitionalphrases, respectively, as set forth in the United States Patent OfficeManual of Patent Examining Procedures, Section 2111.03.

1. A method, comprising: receiving a request that is configured to causea registration of a token commitment on a distributed ledger-basednetwork (DLN), the token commitment representing an asset on the DLN andthe request including an identifying parameter of the asset; providingby a provider, in response to the request and to a self-executing codesegment on the DLN, a zero-knowledge proof (ZKP) that the provider hasknowledge of an identity of an asset token where when a hashing functionis applied to the asset token, the token commitment is generated; andreceiving, after verification of the ZKP by the self-executing codesegment, a confirmation confirming the registration of the tokencommitment on the DLN including an addition of the token commitment ontoa token commitments data structure on the DLN.
 2. The method of claim 1,wherein: the hashing function is a first hashing function; the assettoken is obtained via an application of a second hashing function on theidentifying parameter of the asset.
 3. The method of claim 1, wherein:the hashing function is a first hashing function; the ZKP includes theZKP that the provider of the ZKP has knowledge of the identity of theasset token that when a second hashing function is applied to the assettoken, a first hash value is generated; the token commitment isregistered after the self-executing code segment verifies that the firsthash value is not stored in a double-spend preventer data structure onthe DLN prior to the registration of the token commitment.
 4. The methodof claim 1, wherein: the hashing function is a first hashing function;the ZKP includes the ZKP that the provider of the ZKP has knowledge ofthe identity of the asset token that when a second hashing function isapplied to the asset token, a first hash value is generated; the tokencommitment is registered after the self-executing code segment adds thefirst hash value into a double-spend preventer data structure on the DLNafter verifying that the first hash value is not stored in thedouble-spend preventer data structure.
 5. The method of claim 1, whereinthe token commitment represents a non-fungible token.
 6. The method ofclaim 1, wherein the application of the hashing function includes theapplication of the hashing function on an identifier associated with anowner of the token commitment and/or a random nonce.
 7. The method ofclaim 1, wherein the application of the hashing function includes theapplication of the hashing function on an identifier associated with anowner of the token commitment and/or a random nonce, the identifierincluding a public key of the owner on the DLN.
 8. The method of claim1, wherein the ZKP and/or the verification of the ZKP do not reveal theidentifying parameter of the asset and/or a random nonce used togenerate the token commitment on the DLN.
 9. The method of claim 1,wherein the registration of the token commitment occurs withoutrevealing any identifying information of the asset, any identifyinginformation of the asset, and/or a random nonce used to generate thetoken commitment on the DLN.
 10. A method, comprising: receiving arequest that is configured to cause a transfer of an asset from a senderto a recipient, the asset represented on a distributed ledger-basednetwork (DLN) by a first token commitment; providing by a provider, inresponse to the request and to a self-executing code segment on the DLN,a zero-knowledge proof (ZKP) that the provider of the ZKP has knowledgeof an identity of an asset token, (1) an application of a first hashingfunction on the asset token generating the first token commitment,and/or (2) an application of a second hashing function on the assettoken generating a second token commitment representing the asset on theDLN; and receiving, upon verification of the ZKP by the self-executingcode segment, a confirmation confirming an addition of the second tokencommitment onto a token commitments data structure on the DLN.
 11. Themethod of claim 10, wherein the ZKP includes the ZKP that the providerhas knowledge of an identity of: (a) a first identifier associated withthe sender, the application of the first hashing function including theapplication of the first hashing function on the first identifier,and/or (b) a second identifier associated with the recipient, theapplication of the second hashing function including the application ofthe second hashing function on the second identifier.
 12. The method ofclaim 10, wherein the ZKP includes the ZKP that the provider hasknowledge of an identity of: (a) a first identifier associated with thesender, the application of the first hashing function including theapplication of the first hashing function on the first identifier, thefirst identifier including a public key of the sender on the DLN, and/or(b) a second identifier associated with the recipient, the applicationof the second hashing function including the application of the secondhashing function on the second identifier, the second identifierincluding a public key of the recipient on the DLN.
 13. The method ofclaim 10, wherein the ZKP includes the ZKP that the provider hasknowledge of an identity of a nullifier obtained via an application of athird hashing function on a random nonce and/or a secret identifierassociated with the sender, a presence of the nullifier in a nullifierdata structure on the DLN indicating invalidity of the first tokencommitment.
 14. The method of claim 10, wherein the ZKP includes the ZKPthat the provider has knowledge of an identity of a nullifier obtainedvia an application of a third hashing function on a random nonce and/ora secret identifier associated with the sender, a presence of thenullifier in a nullifier data structure on the DLN indicating invalidityof the first token commitment, the application of the first hashingfunction including the application of the first hashing function on therandom nonce.
 15. The method of claim 10, wherein the ZKP includes theZKP that the provider has knowledge of an identity of a nullifierobtained via an application of a third hashing function on the randomnonce and/or a secret identifier associated with the sender, a presenceof the nullifier in a nullifier data structure on the DLN indicatinginvalidity of the first token commitment, the secret identifierincluding the private key of the sender.
 16. The method of claim 10,wherein the ZKP includes the ZKP that the provider is capable ofderiving a public identifier associated with the sender from a secretidentifier associated with the sender.
 17. The method of claim 10,wherein the ZKP includes the ZKP that the provider is capable ofderiving a public identifier associated with the sender from a secretidentifier associated with the sender, the public identifier and thesecret identifier including a public key and a private key,respectively, of the sender on the DLN.
 18. The method of claim 10,wherein the second token commitment is added onto the commitments datastructure after the self-executing code segment verifies a nullifier isnot stored in a nullifier data structure on the DLN, a presence of thenullifier in the nullifier data structure indicating invalidity of thefirst token commitment.
 19. The method of claim 10, wherein the secondtoken commitment is added onto the commitments data structure after theself-executing code segment adds a nullifier into a nullifier datastructure on the DLN after verifying that the nullifier is not stored inthe nullifier data structure, a presence of the nullifier in thenullifier data structure indicating invalidity of the first tokencommitment.
 20. The method of claim 10, wherein the verification of theZKP by the self-executing code segment occurs without revealing anyidentifying information of the asset on the DLN. 21-30. (canceled)